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1 Docket No. 4020 

2 SPECIFICATION 

3 TITLE: EMERGENCY VEHICLE TRAFFIC SIGNAL PREEMPTION SYSTEM 

4 This application is a Continuation-In-Part of Application 

5 Serial No. 10/642,435, filed August 15, 2003, and Application 

6 Serial No. 60/403,916 filed August 15, 2002. The invention 

7 described herein was made in the performance of work under a 

8 NASA contract and is subject to the provisions of Public Law 

9 96-517 (U.S.C. 202) in which the Contractor has elected to 

10 retain title. 

11 BACKGROUND OF THE INVENTION 

12 1. Field of the Invention 

13 This invention relates to systems for controlling vehicle 

14 traffic signals to allow safe passage of emergency vehicles and 

15 more particularly relates to a system for autonomously 

16 preempting traffic signals at an intersection that includes a 

17 vehicle transponder, a real-time intersection controller and 

18 monitor (with an intersection-based visual and/or audio alarm 

19 warning system) , an operations display and control software, 

20 and a wide-area communications network. 

21 2. Background Information 

22 Present systems used to preempt traffic signals and clear 

23 intersections for emergency vehicles responding to a life- 

24 saving event often come with severe limitations. They rely on: 
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1 sound activation, optical activation, direct microwave 

2 activation, and a combination of all the above. All of these 

3 systems have severe operational limitations affected by 

4 weather, line of sight, and critical range. These systems 

5 often have further drawbacks requiring them to be activated by 

6 the emergency vehicle operator or first responder (herein 

7 referred to as "e -operator") . These systems also severely 

8 disrupt the normal phasing patterns of a traffic controller' s 

9 nominal programming because these systems do not provide real- 

10 time monitoring of intersection phases or timing. 

11 Emergency vehicles currently rely on vehicle horn, sirens, 

12 and flashing lights to prevent accidental collisions with 

13 pedestrians or other vehicles at intersections. E-operators 

14 must focus all their attention on driving the vehicles. Other 

15 preemption systems fail to provide visual or audio feedback 

16 systems (to either motorists or e-operators) that are 

17 physically located in the intersection (herein referred to as 

18 w intersection-based warnings") . Such preemption systems 

19 compromise motorist and e-operator safety, as there is no 

20 awareness of a traffic-light preemption event (referred herein 

21 as "silent preemption") . Additionally, these systems fail to 

22 provide real-time feedback to e-operators through warning 

23 devices inside their vehicles (herein referred to as "vehicle- 

24 based warnings") . These factors have the effect that e- 
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1 operators do not get the feedback required and soon stop using 

2 the system. 

3 An intersection-based preemption system that provides 

4 feedback and is activated autonomously by an approaching 

5 emergency vehicle is needed. Such a system overcomes some of 

6 the drawbacks of available systems. Intersection-based visual 

7 warnings are proven effective for motorists, and are also 

8 critically important to e-operators when multiple emergency 

9 vehicles are approaching the same intersections (referred 

10 herein as "conflict detection") . These displays are directly 

11 in their f ield-of-vision and e-operators are immediately aware 

12 of potential conflicts. Human factors studies often refer to 

13 such indicators as "real-world". Intersection-based warnings 

14 combined with autonomous activation removes the distraction by 

15 keeping drivers' eyes on the road. 

16 A system is needed that takes special consideration of 

17 pedestrians. Visual intersection-based warnings may fail to 

18 get the attention of pedestrians standing near an intersection. 

19 For this reason, audible alerts in addition to visual may be 

20 the most effective (and rapid) warning system of the approach 

21 of emergency vehicles. There is also the difficulty that 

22 pedestrians may often be in harms way if they fail to hear an 

23 approaching emergency vehicle. Although vehicle sirens are 

24 especially loud, many circumstances can lead to dangerous 
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1 situations and potential injury. For instance, an especially 

2 long crosswalk may take up to 20 seconds to cross. In that 

3 time, an emergency vehicle may be heard, perhaps stranding the 

4 pedestrian in the middle of a crosswalk. Likewise, in 

5 extremely busy metropolitan intersections, ambient noise in the 

6 building occlusions may prevent warning of the emergency 

7 vehicle until just seconds before the vehicle arrived at an 

8 intersection. A system is needed that disables normal 

9 pedestrian clearance at intersections long before actual 

10 preemption has been triggered (herein referred to as 

11 "pedestrian-inhibit") . This system would greatly enhance the 

12 safety of emergency vehicle preemption by preventing 

13 pedestrians from entering an intersection long before a vehicle 

14 arrives (or can be seen or heard) . 

15 Existing preemption systems provide little or no 

16 visibility, configuration control, or remote interaction with 

17 their operation or function. A system is needed that provides 

18 real-time feedback, monitoring, logging, and control of vehicle 

19 and intersection preemption-related data. This data would be 

20 displayed at both mobile stations and central operation 

21 center (s). Additionally, a system is needed that provides 

22 secure, robust transfer of data to/from intersections, 

23 vehicles, and operation center (s) using either wireless or LAN 

24 architectures. All of these functions enable logistical 
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1 commanders and traffic management authorities to coordinate , 

2 configure, and monitor activity in the overall preemption 

3 network . 

4 It is one object of the present invention to provide an 

5 emergency vehicle traffic signal preemption system that is 

6 full Y autonomous and not dependent on the intersection being in 

7 visual range. 

8 Still another object of the present invention is to 

9 provide an emergency vehicle traffic signal preemption system 

10 that includes a real-time monitor of intersection phase to 

11 optimize triggers and timing for both preempt and pedestrian- 

12 inhibit functions. This includes minimizing disruption of 

13 normal traffic controller behavior and sequencing. 

14 Still another object of the present invention is to 

15 provide an emergency vehicle traffic preemption system that 

16 includes visual displays in the intersections (and interfaces 

17 to such displays) indicating direction and location of 

18 approaching emergency vehicle (s) . 

19 Still another object of the present invention is to 

20 provide an emergency vehicle traffic signal preemption system 

21 that provides conflict detection (between emergency vehicles 

22 and e-operators) and alerts other emergency vehicles in the 

23 area. This conflict detection is provided in two forms: 

24 intersection-based warnings and vehicle-based warnings . 
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1 Still another object of the present invention is to 

2 provide an emergency vehicle traffic signal preemption system 

3 that includes a pedestrian audio warning signal to supplement 

4 the intersection-based visual display and the audio signals 

5 from emergency vehicles . 

6 Yet another object of the present invention is to provide 

7 an emergency vehicle preemption system having an autonomous 

8 emergency vehicle transponder including an on-board diagnostic 

9 (OBD) interface, a real-time navigation interface and position 

10 estimation module, and a communications monitor and control 

11 interface . 

12 Still another object of the present invention is to 

13 provide an emergency vehicle traffic signal preemption system 

14 that allows real-time remote access, monitoring, and tracking 

15 of the entire preemption system via secure wide -area networks 

16 (wireless and LAN) . This includes access to the operations 

17 display and control software (herein referred to as "operations 

18 software") from management centers (IMC, 911-call center, 

19 etc.) , mobile commanders, as well as individual emergency 

20 responder vehicles . 

21 BRIEF DESCRIPTION OF THE INVENTION 

22 The purpose of the present invention is to provide an 

23 improved emergency vehicle traffic signal preemption system 

24 including autonomous operation, real-time phase monitoring and 
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1 visual/audio signals to alert motorists and pedestrians of the 

2 approach of emergency vehicles . 

3 The system is fully autonomous and is not affected by 

4 range, weather, or line of sight. It provides real-time 

5 monitoring of the intersection phases to optimize intersection 

6 timing and provide the visual display to alert motorist of 

7 oncoming emergency vehicle and the direction it is coming from. 

8 This system is an improvement for use with the system disclosed 

9 and described in U.S. Patent No. 4,704,610 of Smith et al 

10 issued November 3, 1987 and incorporated herein by reference. 

11 The system also provides an added feature of conflict 

12 indication inside the emergency vehicle operator, indicating 

13 that another emergency vehicle is responding and is approaching 

14 the same intersection, indicating which vehicle has the 

15 preemption and right of way. 

16 This system is unique in that it is fully autonomous and 

17 not dependent on the intersection being in visual range. It 

18 provides conflict detection and alerts other emergency vehicle 

19 operators in the area, has the ability to interrupt pedestrian 

20 access, stops preemption when an emergency vehicle stops, and 

21 provides interface to and control of the system disclosed and 

22 described in the above -identified patent. 

23 The improved emergency vehicle traffic signal preemption 

24 system consists of three major subsystems. An intersection 
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1 monitor and control, an emergency vehicle transponder and its 

2 interfaces, and a wide area communications network and its 

3 associated proprietary control program software. The emergency 

4 vehicle intersection preemption design connects intersections 

5 and vehicles over a two-way wide area wireless communications 

6 network. This network is synchronized via Global Positioning 

7 System (GPS) timing signals. The system is also capable of 

8 using existing traffic management LAN networks to relay data to 

9 operations center (s). 

10 When an e-operator receives an emergency response request, 

11 the vehicle is placed in a priority-code (i.e. Code-3) mode 

12 with lights and sirens operating. The vehicle emergency state 

13 is read via an emergency -code vehicle interface. At the same 

14 moment, the vehicle preemption transponder reads the vehicle 

15 on-board diagnostics (OBD) data and determines speed and 

16 acceleration, and gathers navigation data from one of several 

17 navigation systems. This data is collected by an on-board 

18 microprocessor that processes this information and predicts 

19 heading and position. Estimation techniques include (but are 

20 not limited to) dead reckoning and position hysteresis - 

21 historical dependence - and are dependent on the sensor data 

22 quality. This information is then formatted, the vehicle 

23 identification (ID) and absolute time added, and the data is 

24 then transmitted to various both intersections and vehicles 
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1 within the design area of coverage. The data is also 

2 immediately forwarded along the network to subscribing mobile 

3 and fixed operations center (s) . 

4 Intersection processors receive the data, identify the 

5 vehicle' s estimate -time -of -arrival (ETA) , and compare it with 

6 other vehicles possibly approaching their locations. It then 

7 determines which vehicle obtains highest priority (depending on 

8 location history, priority- type of vehicle, and other factors) . 

9 The processor sends notification to all approaching emergency 

10 vehicles, warns of any potential conflict, and notifies the 

11 local e-operators which vehicle has the right of way. 

12 Simultaneously the processor collects real-time 

13 intersection phasing and timing information and calculates when 

14 preemption should start based on the vehicle (s) ETA. The 

15 system includes the real-time monitoring of analog, digital, 

16 and stand-alone (disabled monitoring) controllers. This 

17 monitoring optimizes preempt behavior and provides a closed- 

18 loop verification that preempt commands are executed by the 

19 intersection controller. 

20 It also calculates when to trigger the pedestrian-inhibit 

21 function to prevent clearance for crossing access. When 

22 preemption starts, intersection-based warning displays are sent 

23 coded commands via a wireless or hard-line connection to light 

24 the proper icons. For each direction, the displays show all 
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1 preempting emergency vehicles' direction and location, and 

2 light the appropriate emergency vehicle message (i.e. "Warning 

3 Emergency Vehicle") . All this takes place in real time, in a 

4 manner appropriate to insure an intersection is preempted early 

5 enough for safe and clear access , and in such a way as to 

6 minimized speed reduction for the emergency vehicles. 

7 The system disclosed herein provides a number of 

8 improvements of the above -identified patent. It is an 

9 autonomous system that does not need involvement of emergency 

10 vehicle operator. It also includes expanded system 

11 capabilities using emergency vehicle on-board diagnostics 

12 (OBD) , monitoring multiple emergency vehicles approaching the 

13 same intersection using Global Positioning System (GPS) , and 

14 speed and heading information for multiple emergency vehicles 

15 to determine the right of way. An intersection status is 

16 transmitted to emergency vehicle dashboards indicating when the 

17 intersection is safe to traverse. A dashboard display 

18 indicates to the vehicle operator the status of an 

19 intersection. The system is also capable of providing dynamic 

20 and customized displays via an interface to the vehicle-based 

21 PC (personal computer) systems. This interface provides 

22 detailed, real-time positioning and status of all neighboring 

23 emergency vehicles and intersections. It allows e-operators to 

24 view maps with active vehicles and also allows for enhanced 
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1 conflict detection notification. The system also includes a 

2 wide area wireless RF communication links between emergency 

3 vehicles and intersections. This system is reliable and 

4 unaffected by weather, rain, or lack of line of sight. 

5 Simultaneous to preemption triggers, pedestrian audio 

6 alerts are activated when emergency vehicles are approaching an 

7 intersection. These are important because often visual signs 

8 at an intersection may not be clearly visible to a pedestrian. 

9 Beepers, bells, sirens, or even spoken instructions at high 

10 volume can be used. 

11 Several types of emergency vehicle location and navigation 

12 information retrieval are possible. Among these are Global 

13 Positioning Systems (GPS) , dead reckoning, beacon 

14 triangulation, tags, traffic loop, RDIF, etc. Each vehicle has 

15 an identification (ID) tag that allows transmission to the 

16 appropriate vehicle that it has the right-of-way to a preempted 

17 intersection. 

18 The improvements to the existing system in the above - 

19 identified patent are to enhance the performance but the 

20 purpose of the system remains the same. That is, to alert and 

21 stop vehicles and pedestrians from using an intersection and to 

22 allow an emergency vehicle to pass safely. Some prior warning 

23 is necessary to allow clearing the intersection. The previous 

24 implementation uses a one-way infrared link to transmit 
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1 approach and departure information of emergency vehicle to the 

2 intersection which is equipped with four emergency vehicle 

3 status display panels mounted next to the usual traffic lights 

4 at each intersection. 

5 The system transmits a signal causing all traffic lights 

6 at an intersection to switch to "red" thus stopping all traffic 

7 in all directions. In addition, the display panels flash a 

8 relatively large "emergency vehicle" therein with a graphic 

9 display indicating the lane and direction of traffic taken by 

10 an emergency vehicle. The range of the infrared transmitter 

11 can be as much as 1,000 feet allowing sufficient time to clear 

12 the intersection. The new improved system utilizes a wide area 

13 wireless RF two-way communication link between emergency 

14 vehicles and intersections. This method is more reliable and 

15 not affected by weather, lack of line of sight, range 

16 limitation or obstructions . 

17 Another advantage of the two-way wireless RF 

18 communications link between the intersections and emergency 

19 vehicles is the ability to display much more useful data in the 

20 vehicles helping the vehicle operator maneuver his vehicle most 

21 efficiently and safely. This data includes (but is not limited 

22 to) emergency-code levels, vehicle acceleration, vehicle type, 

23 and vehicle health. This method also enables feedback 

24 communication to be sent from the intersections to the 
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1 vehicles, providing vehicle-based warnings (or confirmation) of 

2 system activity. Intersection "green" status shows when an 

3 intersection has been preempted and priority is given to the 

4 receiving vehicle, allowing safe passage. If more than one 

5 emergency vehicle approaches an intersection, the system 

6 determines which vehicle should have the right of way depending 

7 on location information (GPS, traffic loop, beacon, etc.), 

8 direction and speed sent to the intersection control . A 

9 proprietary control program determines the right of way and 

10 sends the result to emergency vehicles. The encrypted data 

11 package transmitted over transceivers is tagged with the 

12 vehicle ID and time to insure proper and certified utilization. 

13 Another improvement to the system is an audio warning 

14 system intended to alert pedestrians that an intersection has 

15 been preempted and must be kept clear. One desirable 

16 implementation would utilize loudspeakers mounted near the four 

17 corners of the intersection where pedestrians normally gather 

18 to cross. A spoken message, such as "warning, emergency 

19 vehicle approaching, do not walk", may be most preferred but 

20 any audible signal such as a wailing sound, a siren, or any 

21 other familiar emergency sound may be utilized. 

22 Another goal of the improved system is creation of an 

23 autonomous system that is activated by reception of a priority- 

24 code (i.e. Code-3) status or alarm. The operator of the 
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emergency vehicle can concentrate on his primary duty which is 
to arrive at the sight of the emergency safely in the shortest 
time possible without worrying about the activation of the 
system. A priority-code starts the process of communication 
between an intersection that is being approached and the 
emergency vehicle and the system performs the functions 
described above. Also, both vehicle-based warnings and 
intersection-based warnings provide positive feedback that an 
e-operator has secured an intersection. This directly 
translates into a reduction of emergency workers' stress 
levels . 

The information available from the emergency vehicle and 
intersection controllers may be transmitted to a central 
location such as a dispatch center or traffic control center to 
display the status of multiplicity of intersections and 
emergency vehicles. Such information being displayed on a 
status board can be invaluable in managing emergency situations 
(especially large-scale incidents) in a more sufficient manner 
because it makes available information on a real-time basis for 
the officials in charge. Commands and configuration 
information can also be sent back to intersections and vehicles 
to instantly meet changing needs or requirements. These 
instructions can include the creation of large emergency 
corridors (herein referred to as an "e-corridor") whereby a 
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1 series of sequential intersections are preempted in the same 

2 direction. 

3 The above and other objects, advantages, and novel 

4 features of the invention will be more fully understood from 

5 the following detailed description and the accompanying 

6 drawings, in which: 

7 BRIEF DESCRIPTION OF THE DRAWINGS 

8 Figure 1 is a block diagram of the functions of 

9 intersection hardware for the emergency vehicle traffic signal 

10 preemption system (herein referred to as "preemption system") , 

11 as used for interfacing with all intersection controllers. 

12 Figure 2 is a block diagram of the functions in an 

13 emergency vehicle transponder for the preemption system. 

14 Figure 3 is an example schematic block diagram of a 

15 standard vehicle transponder for the preemption system. 

16 Figure 4 is an example schematic diagram of a vehicle dn- 

17 board diagnostic (OBD) circuit for the preemption system. 

18 Figure 5 is a functional organizational diagram of the 

19 three major subsystems for the preemption system. 

20 Figure 6 is a schematic block diagram of the intersection 

21 hardware for the preemption system, as configured for 

22 interfacing to an intersection controller without monitoring. 

23 Figure 7 is a schematic block diagram of the intersection 

24 hardware for the preemption system, as configured for 
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1 interfacing to an intersection controller with digital BUS 

2 monitoring. 

3 Figure 8 is a schematic block diagram of the intersection 

4 hardware for the preemption system, as configured for 

5 interfacing to an intersection controller with analog 

6 monitoring. 

7 Figure 9 is a general flow diagram of the intersection 

8 control program software for the preemption system. 

9 Figure 10 is a general flow diagram of the vehicle 

10 transponder control program software for the preemption system. 

11 Figure 11 is a detailed decision flow diagram of the 

12 preempt monitor task component for the intersection control 

13 program software. 

14 Figure 12 is a detailed time sequence diagram of the 

15 standard preemption criteria used by the intersection control 

16 program software in a typical preemption scenario. 

17 Figure 13 is a layout and topology diagram of the 

18 communications and operations network for the preemption 

19 system. 

20 Figure 14 is a block diagram of the functions and data 

21 flow of the operations software for the preemption system. 

22 Figure 15 is an example of the data status module display 

23 component and alerts module display component, used in the 

24 operations software for the preemption system. 
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1 Figure 16 is an example of the intersections module 

2 display component, used in the operations software for the 

3 preemption system. 

4 Figure 17 is an example of the vehicles module display 

5 component and the mapping module display component, used in the 

6 operations software for the preemption system. 

7 DETAILED DESCRIPTION OF THE INVENTION 

8 The three major subsystems in the emergency vehicle 

9 traffic signal preemption system are shown in Figure 5: the 

10 vehicle transponder 200, the intersection hardware 230, and the 

11 communications and operations network 260. 

12 The vehicle transponder 200 is composed of three main 

13 components. First, the vehicle computer interface module 205 

14 includes the on-board diagnostics circuit and the emergency 

15 priority code interface. Second, the navigation predict module 

16 210 uses navigation sensors such as GPS and INU (inertial NAV 

17 unit) sensors to generate both absolute and estimated dead 

18 reckoning position reports. Third, the transponder control 

19 module 215 provides an interface to the e-operator via LEDs , PC 

20 display, or PDA device. 

21 The intersection hardware 230 is composed of three main 

22 components. First, the intersection monitor module 235 

23 provides real-time reading and logging of controller signal and 

24 pedestrian phasing and timing. Second, the intersection 



17 



1 control module 240 performs ETA calculations using vehicle 

2 positions and local known mapping topology (commonly known as 

3 map-matching) . This module also tracks and logs vehicles, 

4 actuates and verifies preempt signals, manages communications 

5 between other networked units, and manages remotely -gene rated 

6 intersection configuration commands. Third, the warning alerts 

7 control module 245 actuates intersection -based visual and/or 

8 audio warnings . This module also ensures that warning alerts 

9 follow specific rules and timing parameters that govern the 

10 sequencing of warning signs with traffic lights. 

11 The communications and operations network 260 is composed 

12 of three main components. First, the slave (end-unit) 

13 transceivers in vehicles and intersections 275 relay the core 

14 preemption status and configuration data to the backbone 

15 network. Second, the backbone wireless or LAN network 270 is a 

16 hybrid wide-area network designed to route data between mobile 

17 wireless vehicles, hard-lined and isolated wireless 

18 intersections, and the central operation center (s) . Third, the 

19 operations software 265 provides for display of all real-time 

20 data generated by the intersections and vehicles including 

21 positions/speed, phasing, preemption-status, vehicle 

22 diagnostics, logged information, configuration data, and many 

23 other data parameters. This display/control software 265 can 

24 be mobilized for use in any management center, staging area, or 
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even an entire fleet of emergency vehicles. 

The functional details of the major subsystems in the 
emergency vehicle traffic signal preemption system are 
illustrated in the block diagrams of Figure 1, Figure 2, and 
Figure 13. Figure 1 illustrates the functional details of the 
system at each intersection, Figure 2 illustrates the functions 
of the system installed in an emergency vehicle, and Figure 13 
illustrates the topology and display/ control software used for 
the communications and operations network. 

Traffic light control system 100 at an intersection 
includes traffic light controller 20 (housed in cabinet 500) 
that generates the appropriate sequence of on-time and off-time 
for the various traffic lights that controls vehicular and 
pedestrian traffic at an intersection. Traffic light 
controller 20 also has the capability to be forced by external 
signals into a mode that activates "green" lights in a 
specified direction and "red" lights in all other directions, 
allowing safe passage for emergency vehicles from the "green" 
direction. Controller 20 is preferably a micro-processing 
circuit driving isolated lamp drivers but discrete designs are 
also feasible. Some intersections may be more complicated, 
controlling turn lanes with arrow lights, but the basic 
principles remain the same. 

An example of an intersection being controlled by the 
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1 system and functions disclosed and describe herein is shown in 

2 Figure 1 of U.S. Patent No. 4,704,610 referred to hereinabove 

3 and incorporated herein by reference. This figure shows the 

4 signage and approach of emergency vehicles being controlled. 

5 The only feature missing is the pedestrian control signs at 

6 each corner which are an added feature of the invention 

7 disclosed and described herein. 

8 Traffic light controller 20 generates signals to control 

9 pedestrian lights 22a, 22b, 22c, and 22d and also controls the 

10 operation of traffic lights 24a, 24b, 24c, and 24d. An 

11 intersection having traffic lights can be connected to a system 

12 using the emergency vehicle preemption system by addition of 

13 the functions described hereinafter without the need to rebuild 

14 an existing installation. 

15 The heart of the additional equipment is the intersection 

16 control module, a microprocessor 515 (e.g. , a ZWorld LP 3100 

17 CPU) operated by proprietary control program software 35. 

18 Controller 10 (housed in hardware module 510) receives 

19 information from emergency vehicles that approach an 

20 intersection via wireless RF transceiver 40 and antenna 41. 

21 This information contains data about the predicted position, 

22 heading, other navigation data of the emergency vehicle, and 

23 its priority-code status 36 (i.e. Code-3, Code -2 , or other) 

24 thus notifying the intersection of its relative location. 



20 



1 Figure 9 illustrates the general functionality of the 

2 intersection control program software and firmware 35 (see 

3 Appendix B) . The vehicle monitor software task 605 running on 

4 the intersection CPU 515 tracks all local vehicles and 

5 maintains a log of all activity. The task also sends conflict 

6 detection warnings, when appropriate, to the vehicles. 

7 The intersection control program 35 continually evaluates 

8 its preemption rules as vehicle updates are received. Position 

9 and priority parameters of each vehicle within range are 

10 analyzed by the intersection preempt monitor software task 600. 

11 The primary decision logic of this task is illustrated in 

12 Figure 11. Appendix A provides detailed explanations of the 

13 terms and parameters used in this figure and the description 

14 below. The preempt monitor task uses map-matching techniques 

15 to evaluate all vehicles against all eligible cross street 

16 segments 700 to determine which vehicles are inbound or 

17 outbound 730 from the intersection. The task assigns 

18 preemption priority to that vehicle which is within critical 

19 perimeter zones (pedestrian 705 and preempt 706) , in high 

20 priority priority-code 710, and is a valid vehicle type 720. 

21 In order to optimize the preemption process, it compares the 

22 minimum vehicle-ETA with both the intersection clearance time 

23 (time-to-preempt) and a minimum complete -preemption time 

24 (threshold) 715. 
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1 Figure 12 provides a visual illustration of the logic of 

2 the intersection preempt monitor software task. The diagram 

3 shows the actual positions (p # ) based in time along the actual 

4 path 621 of the vehicle. For every actual position (p#) , there 

5 is a same-time position report <e#) along the estimated path 620 

6 of the vehicle. For instance, p x 623 and e x 622 both occur at 

7 same time t x . The diagram illustrates the estimate path 620 

8 with valid position-lock (i.e. GPS occlusion) , as well as 

9 temporary loss of position-lock 624 when dead reckoning is used 

10 to compensate. The diagram also illustrates the multiple uses 

11 of proximity (perimeter) layers, with a pedestrian-inhibit 

12 perimeter 625 ( "max -PED -perimeter" ) , a preempt! on -all owed 

13 perimeter 626 ("max -preempt -perimeter") , a critical distance 

14 perimeter 627, and multiple critical distance street segments 

15 628. Non-critical segments 636 are also shown (these street 

16 segments require additional evaluation based on vehicle-ETA) . 

17 The exit window 631 displays an example exit distance range 

18 where egress intersection-based warnings are allowed to be 

19 activated (based on configurable minimum and maximum exit 

20 distance criteria) . Also, the evaluation of vehicle heading 

21 compared against the road heading is shown as the direction- 

22 error 622. The acceptable deviation of the estimated position 

23 from the center-line of the street 630 is also shown. 

24 Figure 12 also shows one of the more advanced preemption 
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1 techniques used on the intersection control program, the use of 

2 " threshold-lag" 640, 641, and 642. "Threshold-lag" is defined 

3 in Appendix-A. In simple terms it is percentage error factor 

4 added to the threshold that gives the "benefit -of -the -doubt" to 

5 any actively preempting vehicle. Initially (prior to 

6 preemption) , the threshold-lag factor 640 is zero percent (0%) . 

7 When the threshold is crossed, the threshold-lag becomes its 

8 maximum value (i.e. 30%) , and it is added to both the 

9 threshold- time and the time -to -preempt factors for comparison 

10 to vehicle-ETA. Once a vehicle has crossed the threshold, and 

11 the threshold-lag has been expanded, the threshold-lag linearly 

12 decreases back to zero percent (0%) over a small period (i.e. 

13 10 seconds) . This calculation is just one form of hysteresis 

14 (historical dependence) techniques used in the invention. 

15 Figures 6, 7 and 8 are schematics that show detailed 

16 layouts of the intersection hardware components and, most 

17 specifically, multiple configurations for real-time monitoring 

18 of phasing/ timing controller signals. The configuration in 

19 Figure 7 provides for interfacing to digital BUS intersection 

20 controllers 20b (such as NEMA TS1 controller models) . The 

21 configuration in Figure 8 provides for interfacing to analog- 

22 based intersection controllers 20c (such as type 170 controller 

23 models). On such analog systems, traffic lights signals are 

24 monitored by a fail-safe, isolated, high impedance tap and 
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1 subsequent digital circuit processing. The monitor data is 

2 available for remote monitoring via the wide area 

3 communications and operations network. As shown in Figure 6, 

4 the system is still compatible with controllers that disable 

5 monitoring 20a or where monitoring is not desired. 

6 Real-time monitor information is read and analyzed by the 

7 intersection monitor software task 610. These calculated 

8 values are forwarded to the preempt monitor 600 , where these 

9 intersection phasing values are integrated with real-time 

10 vehicle information. The software attempts to optimize preempt 

11 triggers with "time -to -preempt" calculations and "time-to- 

12 pedestrian-inhibit" calculations, as compared to the ETA of all 

13 approaching emergency vehicles. The goal is to provide minimal 

14 disruption to the nominal controller behavior and to maximize 

15 the throughput of emergency vehicles through the preemption 

16 intersection network. Also, unlike other preemption systems, 

17 beyond simply sending a preempt command (actuating a preempt 

18 signal) , the real-time monitor independently measures the state 

19 of the controller-actuated traffic light signals. This 

20 provides a critical closed-loop design: it assures that preempt 

21 commands are actually executed. 

22 Real-time status monitor 42 is unique because it verifies 

23 the state of the traffic signals and sends the intersection 

24 status (i.e. "intersection preempted" , "conflict detected" , or 
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1 "no preemption") to intersection control module 10. That is, 

2 real-time status monitor receives (i.e., "reads") the output 

3 from traffic light controller 20 and pedestrian lights 22a 

4 through 22d and traffic lights 24a through 24d and transmits 

5 that information to intersection control module 10 . 

6 Intersection control module 10 in turn relays that information 

7 to emergency vehicles via wireless RF transceiver 40 and 

8 antenna 41. Intersection control module 10 now sends signals 

9 to emergency display panels 45a, 45b, 45c, and 45d to light and 

10 flash large emergency signs with the proper icons at each 

11 corner of an intersection showing the position of any 

12 approaching emergency vehicle relative to the traffic lanes of 

13 the intersection as shown and described in the above -identified 

14 U.S. patent incorporated herein. The display panels 45a-45d 

15 and proper icons used at each corner of an intersection are 

16 shown in Figure 2 of the U.S. patent referenced hereinabove. 

17 The signage is also illustrated in U.S. Design Patent No. 

18 305,673, issued January 23, 1990, and also incorporated herein 

19 by reference. 

20 Also, the real-time status monitor 42 provides which is 

21 transmitted via RF master transceiver (or LAN) 60 and antenna 

22 61 to a central monitoring system such as a dispatcher's 

23 office. Reciprocally, the intersection receives information on 

24 the state of its neighboring intersections. This closed-loop 
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1 architecture allows various units in the network to accurately 

2 predict future movement, log critical information, and notify 

3 users of the system state. 

4 The intersection control program 35 (specifically the 

5 preempt monitor software task 600) uses map-matching techniques 

6 to compare vehicle navigation and position estimates with the 

7 approach paths (cross-streets stored locally as map vectors) . 

8 This way the intersection can determine if any vehicle is on an 

9 inbound course towards the intersection by "snapping" it to the 

10 closest street. As an example, one of the calculations is the 

11 "critical distance" test. This evaluates whether an 

12 approaching car has statistically committed itself to crossing 

13 through the local intersection based on lack of turning 

14 options. Because of the knowledge of the road map, the 

15 intersection can preempt even when the "critical distance" is 

16 not line-of -sight . As an additional example, in the event that 

17 any vehicle comes with a "warning distance" of the intersection 

18 (1000-ft commonly used) , the control program 35 will actuate 

19 pedestrian-inhibit functions. Pedestrian lights 22a through 

20 22d are changed to prevent pedestrian traffic. Through a 

21 combination of hysteresis-based (historical dependence) 

22 algorithms and dynamic proximity "windows", the system is able 

23 to optimally route emergency vehicles across the map grid. It 

24 is also able to effectively mitigate lossy communications, 
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lossy navigation data, and other unpredictable delays in the 
system. 

Another improvement to the system is the provision of an 
audio warning to pedestrians. Thus simultaneously with 
controlling the lights and pedestrian flashing signals, 
controller 10 generates an audio message to be delivered from 
audio warning device 50 to speakers 51a through 51d. 

As mentioned, the details of the software in the 
intersection control program for implementing the functions of 
the system are provided in Appendix B. Because the functions 
controlled are described in great detail in the text, many 
software solutions to implement the functions will be apparent 
to those skilled in the art. 

Emergency vehicle functions for the preemption system are 
illustrated in the block diagram of Figure 2 . A transponder 
box 99 (and cables 98, 98a) are installed in each emergency 
vehicle and provide the functions that facilitate communication 
with preempt-able intersections, other emergency vehicles, and 
also central monitoring stations such as a dispatching center. 
Inputs and outputs to and from the emergency vehicle system are 
handled by transponder control module 30 under the direction of 
proprietary control program software 15. Vehicle parameters 
are determined from several inputs provided to transponder 
control module 30. 
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Vehicle position is available from GPS receiver 38 via 
antenna 39. Several positioning inputs 96 are available from 
ports in navigation input device 34. Optional alternative 
inputs from ports and navigation input device 34 are INU 
(inertial navigation and estimation unit 29) parameters 
including accelerometers , gyroscopes, wheel-tachometers , and 
heading indicators. Other inputs include ID tag tracking, 
beacon triangulation , modified traffic loop detectors, and 
others. Vehicle information such as speed and acceleration are 
read in real-time from the vehicle computer 33 using the on- 
board diagnostic (OBD) interface cable and connector 33a. 
These signals are converted and verified by the OBD circuit 
board 32 and the translated digital signals are input to 
transponder control module 30 (embedded on a micro-controller 
97) . 

The emergency vehicle transponder system communicates with 
intersections via wireless RF transceiver 44 and antenna 45. 
The vehicles and intersections software task 670 running on the 
vehicle transponder handles incoming intersection preempt 
alerts and vehicle position reports from nearby units. It 
receives feedback verification and displays the information on- 
board by activating one or more LEDs 56, 57, or 58 on the LED 
display 54. If it receives a signal for safe passage through 
an intersection, "green" LED 56 is illuminated. If another 
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1 high-priority emergency vehicle is concurrently trying to 

2 preempt the same intersection, "yellow" LED 57 is illuminated. 

3 Illumination of "red" LED 58 indicates that there is no 

4 preemption at the intersection. LEDs 56 through 58 are driven 

5 by "intersection preempted" logic circuit 55. Logic circuit 55 

6 can also provide customized outputs to dynamic display devices 

7 59, such as PC monitor displays (LCD's) and Personal Digital 

8 Assistants (PDA's). Such devices are commonly used for law 

9 enforcement applications within the vehicle. As mentioned, the 

10 operations software shown in Figure 14 can be mobilized 80 and 

11 run on any vehicle-based auxiliary hardware device with a 

12 standard operating system. The vehicle interface software task 

13 665 in the transponder control program allows advanced mapping 

14 and alerting of active nearby intersections and vehicles. 

15 Emergency vehicle status is available in real time via 

16 master RF transceiver 64 and antenna 65 to a central monitoring 

17 station. Thus the position of any vehicle as well as the 

18 status at an intersection is always available at some centrally 

19 located dispatch station. 

20 As indicated previously, the software in control program 

21 15 to implement the functions of the transponder described 

22 above has many possible solutions. Thus the software provided 

23 to control the operation of transponder control module 30 can 

24 be designed and implemented by anyone skilled in the art given 
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1 the detailed explanation of the system and functions described 

2 hereinabove. Also, as previously mentioned, Appendix B 

3 provides detailed pseudo-code of a full-featured version of the 

4 software for both the intersection and vehicle. 

5 Figure 3 is a schematic block diagram of the transponder 

6 system mounted in each vehicle. The transponder box 99 in the 

7 vehicle receives power from car battery through the OBD 

8 interface 33a. The transponder box 99 has a GPS receiver such 

9 as that produced and manufactured by Garmin International 

10 Incorporated. The transceiver can be a radio transceiver 

11 produced and manufactured by Freewave Technologies of Boulder, 

12 Colorado . 

13 Figure 4 is a schematic diagram of the on-board diagnostic 

14 (OBD) circuit for the vehicle-based electronics and 

15 transponder. The on-board diagnostic circuit handles such 

16 information as speed, acceleration, heading, ignition status, 

17 etc. and generates the proper digital signals 96a for delivery 

18 to transponder control module 30 . 

19 Figure 10 illustrates the general functionality of the 

20 vehicle transponder control program software and firmware. The 

21 program monitors and logs all in-range vehicles and 

22 intersections and manages the data output to the operator 

23 display. The core component of the transponder software is the 

24 navigation prediction module software task 655. The task uses 
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1 position estimates by GPS and other absolute position inputs , 

2 and combines data from accelerometers , gyroscopes , tachometers , 

3 and heading indicators. This data is then integrated with 

4 historical logs. This process, commonly known as dead 

5 reckoning, uses accurate (yet possibly intermittent) position 

6 reports integrated with time-based inertial navigation data to 

7 generate enhanced position estimates. Position information is 

8 forwarded to the transponder state and position monitor 

9 software task 650. This task monitors vehicle state and 

10 diagnostic inputs (such as Code-3) and generates position/state 

11 reports to broadcast via the wireless network. 

12 Figure 13 illustrates an example network topology for the 

13 communications and operations network. Emergency vehicles 300 

14 and 301 send navigation reports (i.e. GPS) and other 

15 data/commands (via wireless connection) to/from intersections 

16 and other local vehicles . Preemption-equipped intersections 

17 305, 306, and 307 monitor navigation information from vehicles. 

18 Intersections cooperatively and redundantly communicate with 

19 each other 320 (via wireless or LAN) to enhance data accuracy 

20 and ensure robust communications. Data is also passed along to 

21 existing TMC (traffic management center) 330 using existing 

22 city LAN communications network 325. If a LAN network is not 

23 used, wireless systems can be substituted, such as through FMC 

24 340 (fleet management center) systems. From there, FMC can 
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1 forward all data to/from vehicle and TMC. 

2 Figure 14 is a block diagram of the operations software, 

3 designed for use in central command centers , mobile command 

4 stations , and in individual emergency vehicles . The diagram 

5 illustrates the primary functional components of the software. 

6 The primary components include algorithmic modules and visual 

7 displays . for : low-level data activity 405, priority alerts 410, 

8 intersections' data 420, vehicles' data 430, and geographic 

9 mapping 450. In Figures 15, 16, and 17, both data and displays 

10 for these components are shown in an example preemption 

11 scenario. This example demonstrates the real-time operations 

12 monitoring of a conflict detection scenario, whereby two police 

13 vehicles are approaching the same intersection in high priority 

14 mode. Figure 15 shows incoming data 461 from vehicles and 

15 intersections within the preemption operations communications 

16 network 460. Textual status messages are provided on the data 

17 status module display 405a. The data status module 405 also 

18 maintains a historical record for all low-level communication 

19 and data-flow activity. This module 405 relays all verified 

20 and priority data messages 406 (i.e. position, preempt, and 

21 conflict messages) to the alerts module 410. The alerts module 

22 display 410a provides real-time visual notifications of current 

23 high-priority events (i.e. active Code-3 vehicles and preempted 

24 intersections) and enables rapid analysis of the current 
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1 preemption system status. 

2 The alerts module 410 forwards all detailed data 411 to 

3 the vehicles and intersections modules 420 and 430. The 

4 intersection module display 420a shows real-time detailed 

5 intersection data including the traffic light states 421a 

6 (phasing) and pedestrian clearance states 421b. Also shown are 

7 timing parameters 421c (for example, minimum ETA to 

8 intersection for inbound direction) and display data (for 

9 example, visual warning signs' states) . The vehicle module 

10 display 430a shows real-time detailed vehicle data including 

11 estimated locations, car types, priority-states, navigation 

12 data (such as heading) , and other historical information. 

13 All vehicles' and intersections' active data 411 is 

14 integrated and overlaid on the mapping module display 450a. 

15 The display is an adjustable city map with active units shown 

16 as icons, such as vehicle units 431a, 431b and intersection 

17 units 432. Visual high-priority alerts, such as conflict 

18 detection warnings 433, are logistically overlaid on the map. 

19 A secondary component of the operations software is used 

20 for installation and real-time configuration of units 470 as 

21 they are added to the preemption network . For intersections , 

22 configuration commands 471 include the upload of street grid 

23 databases, phase preemption information, and enter/exit 

24 distance and timing. For vehicles, configuration commands 471 
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1 include ID tags, selection of vehicle type, and sensitivity 

2 settings for navigation algorithms. Various test utilities 

3 allow the installer to visually monitor the intersection and 

4 approaching test vehicles. For instance, the system can be put 

5 into the silent preempt mode (no warning signs) , or can be 

6 manually activated to preempt without a vehicle. The software 

7 can communicate directly with a local intersection or vehicle, 

8 or can use the local unit's transceiver to talk to the rest of 

9 the network. 

10 The operations software can be used to analyze (and 

11 optimize) call response times and call response strategies 

12 (routes, etc.) . It can be used from any location within the 

13 range of the network, and can also be integrated into existing 

14 call-response centers. The software can also be used for 

15 emergency logistics management (i.e. multiple car responses), 

16 preventative warnings (i.e. conflict detection), and can also 

17 be integrated into existing TMC incident management systems. 

18 The system and displays can be accessed via the internet 480 as 

19 well. Traffic technicians can use the system to monitor 

20 phasing and optimize internal controller programming to match 

21 desired preemption settings and behavior. The monitor software 

22 is also able to identify potential problems or conflicts in the 

23 network using intelligent "sniffer" software utilities. These 

24 algorithms watch incoming data to make sure that data is 
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1 disseminated in real-time, that data is cohesive and error- 

2 free, and that position/state reports are consistent. The 

3 system also has the capacity to quickly and autonomously shut 

4 off problem vehicle or intersection units. These utilities 

5 allow the system to quickly identify anomalies and request 

6 maintenance, thereby drastically reducing potentially 

7 significant traffic problems. 

8 Thus there has been disclosed improvements to an emergency 

9 vehicle traffic signal preemption system. Improvements include 

10 providing an autonomous system that is not dependent on 

11 intersection being in visual range. The system provides 

12 conflict detection and alerts emergency vehicle operators in 

13 the area, and provides real-time monitoring of an intersection 

14 phase. The real-time monitoring of intersections is indicated 

15 by LEDs on a transponder or LCD display in the emergency 

16 vehicle that show whether there is a conflict or the 

17 intersection being approached is not preempted. The system 

18 also includes the improvement of an audio alarm to alert 

19 pedestrians who may not be aware of an approaching emergency 

20 vehicle for various reasons or are at an angle where visible 

21 signs are not clear. 

22 This invention is not to be limited by the embodiment 

23 shown in the drawings and described in the description which is 

24 given by way of example and not of limitation, but only in 
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1 accordance with the scope of the appended claims . 
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1 APPENDIX A 

2 The following phrases and definitions are used to describe 

3 preemption-related terms, operator-configured parameters, and 

4 software-derived calculations. These terms specifically relate 

5 to (a) the decision flow diagram in Figure 11, (b) the example 

6 preemption scenario shown in Figure 12, and (c) the decision 



7 criteria used in the intersection preempt monitor software 

8 task : 

9 General Definitions : 

10 "Complete preemption" is the state where a preemption 

11 command has been sent to an intersection controller, and the 

12 command has been completed such that all PED and traffic lights 

13 are "red", except the inbound traffic light for a preempting 

14 emergency vehicle which is "green". 

15 "Street segment" is a line (vector) that when combined 



16 with other contiguous street segments, represent a street map 

17 in the intersection control program software. The segments 

18 identify all local streets near or crossing the intersection. 



19 "Critical-inbound" refers to an emergency vehicle that is 

20 on a cross street segment, inbound based on its heading, and 

21 its ETA or proximity make it eligible for preemption. A 

22 vehicle in this state, except in special circumstances, would 

23 be preempting the intersection. 

24 "Hysteresis" is a historical dependence statistical 
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1 calculation. It uses behavior or rules formed while collecting 

2 previous time-based sequenced data to predict future behavior. 

3 In the context of this preemption system, hysteresis is used to 

4 address such observations as: "if an e-operator successfully 

5 preempts a traffic light, the intersection program should be 

6 very conservative and cautious before discontinuing the 

7 preemption for that vehicle." This basic hysteresis approach 

8 is illustrated in Figures 11 and 12. Advanced approaches use 

9 tracking and prediction algorithms to more accurately assess 

10 vehicle position, e-operator intent, and optimize intersection 

11 controller behavior. 

12 Operator-Configurable Values : 

13 "Max-preempt-perimeter" is the maximum distance at which a 

14 vehicle is allowed to preempt the local intersection. As 

15 example, 3000-ft could be used. 

16 "Street width" is the maximum deviation (distance) allowed 

17 between the line-center of a street segment and a vehicle's 

18 estimated position. If the calculated difference is less than 

19 "street width", the vehicle is considered "on" a street 

20 segment. As example, 50 -ft could be used. 

21 "Heading error" is the maximum deviation (angle) allowed 

22 between the direction of a street segment and a vehicle's 

23 estimate heading. If the difference between angles is less 

24 than the "heading error" , the vehicle is considered to be 
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1 moving "along" that street segment. As example, 15-degrees 

2 could be used. 

3 "Critical distance" is the distance within which a vehicle 

4 is automatically marked as critical -inbound (if heading meets 

5 criteria) . As example, 200-ft could be used. 

6 "Critical segment" is a boolean value that applies to all 

7 street segments; if "yes" then any vehicle "on" that street 

8 segment is automatically marked as critical -inbound (if heading 

9 meets criteria) . 

10 "Max-PED-perimeter" is the distance within which 

11 pedestrian -inhibit is enabled to prevent standard PED clearance 

12 phases. As example, 2200-ft could be used. 

13 "Min-exit-distance" is the minimum outbound distance past 

14 which egress intersection-based warnings are allowed. As 

15 example, 30 -ft could be used. 

16 "Max -exit-distance" is the maximum outbound distance up to 

17 which egress intersection-based warnings are allowed. As 

18 example, 100 -ft could be used. 

19 "Min-exit-speed" is the minimum speed above which outbound 

20 intersection-based warnings are allowed. As example, 5-mph 

21 could be used. 

22 "Min -preempt -speed" is the minimum speed above which 

23 inbound preemption and inbound intersection-based warnings are 

24 allowed. As example, 10-mph could be used. 
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1 "Max-latency" is the maximum time between preempt-able 

2 messages (see latency-counter description) from the same 

3 vehicle before that vehicle is considered inactive. As 

4 example, 6 -sees could be used. 

5 Software Derived/Calculated Values: 

6 "Max-NAV-error" is the maximum estimated distance error 

7 allowed for vehicle-ETA calculations, as determined by dead 

8 reckoning algorithms and positioning device specifications . 

9 Any error exceeding this factor will invalidate the associated 

10 estimated vehicle position. As example, 150-ft could be used. 

11 "Vehicle-ETA" is the minimum estimated ETA (estimated- 

12 time-of -arrival) of a vehicle at an intersection, as calculated 

13 using the real-time map distance between vehicle and 

14 intersection, vehicle speed, vehicle acceleration (based on 

15 historical averaging and vehicle type) , street type, and 

16 expected street conditions (i.e. time -of -day ) . 

17 "Threshold-lag" is the minimum estimated time that the 

18 complete -preempt! on state must remain steady prior to a 

19 preempting vehicle's arrival at an intersection. This 

20 calculation is based on the vehicle' s speed. The purpose of 

21 this factor is to minimize slowing of preempting vehicle. The 

22 lag includes threshold-hysteresis (see below) . 

23 "Threshold-hysteresis" is a percentage time error included 

24 in threshold-lag. When a vehicle preempts an intersection, the 
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1 threshold-hysteresis factor resets from 0% to a percentage of 

2 the initial vehicle-ETA. For example, 30% could be the default 

3 initial setting. Every second thereafter, this percentage is 

4 reduced linearly, until 0%. This ensures that once a vehicle 

5 is preempting, it is unlikely a temporary vehicle change will 

6 disable preemption (i.e. slowing down) . 

7 "Time-to-preempt" is the minimum time to achieve complete 

8 preemption at an intersection, estimated by the real-time 

9 phasing monitor. One of the primary calculations to determine 

10 a vehicle's preempt eligibility is if a vehicle's ETA is less 

11 than the sum of the time-to-preempt and threshold-lag 

12 parameters . 

13 "Latency-counter" is the number of seconds since the last 

14 "valid" preempt-able message was received from a given vehicle. 

15 Some criteria that would cause the latency counter to increment 

16 are: (a) a position report accuracy worse than Max-NAV-error , 

17 (b) vehicle not "on" a street segment, (c) low or no vehicle 

18 speed, or (d) vehicle heading not inbound. 
19 

20 
21 
22 
23 
24 
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1 APPENDIX B 

2 

3 

4 Emergency Vehicle Traffic Signal Preemption System 

5 Vehicle Transponder and Intersection Module Software: 

6 Pseudo-code of Release Versions 
7 

8 // 

9 // 

10 // 

11 // 

12 // The system allows emergency vehicles to preempt traffic intersections 

13 // and also provides visual indication (an LED sign) to motorists of 

14 // approaching emergency vehicles. The system is based on a short-range, 

15 // mobile wireless network with continuous reporting of vehicle state to 

16 // nearby intersections. The software is written in f, C M for the ZWorld 

17 // LP3100 micro-controller. 

18 // 

19 // VEHICLE CONFIGURATION: 

20 // 

21 // This is the vehicle software component of the EViews Emergency 

22 Vehicle 

23 // Preemption System. It determines an emergency vehicle's location and 

24 // speed, identifies the state of the emergency vehicle (i.e. Code-3), 

25 // and transmits this information to a network of intersections. It 

26 also 

27 // provides feedback to the driver: (1) visual indication of whether the 

28 // vehicle is currently preempting an intersection, and (2) area mapping 

29 // data of other nearby emergency vehicles that are in Code-3. 

30 // 

31 // INTERSECTION CONFIGURATION: 

32 // 

33 // This is the intersection component of the EViews Emergency Vehicle 

34 // Preemption System. It monitors nearby vehicles in Code-3 and the 

35 // current timing of all traffic light phases and pedestrian clearance 

36 // phases. It uses these parameters to determine when to disable the 

37 // pedestrian crossing buttons and preempt the traffic signal. It also 

38 // broadcasts the current state of the intersection to the nearby Code-3 

39 // vehicles and other nearby intersections. 

40 // 

41 // MAJOR PARAMETERS USED INCLUDE: 
42 

43 #define IS_TDMA 1 // is TDMA coram being used? 

44 #define MASTER TXMT 1 // is the unit a master (repeater)? 
45 

46 #define TYPE_VEH 0 // type of vehicle (fire, police, etc) 

47 #define TYPE_INT 1 // type of intersection (major, minor, 

48 // route, etc) 
49 

50 /******************************************************/ 

51 // GENERAL COMM AND DATA 

52 /*************************************^ 

53 

54 #define MESSAGE_POS 1 // position report 

55 #define MESSAGE_VID 10 // vehicle ID change 

56 #define MESSAGE__IID 15 // intersection ID change 

57 #define MESSAGE_SEG 20 // intersection segment addition 

58 #define MESSAGE_MSG 30 // textual message 
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// 


write parameters to stored data 
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// 
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// 
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#def ine 


OM~~REC 
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// 
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#def ine 
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// 


output eviews info? 
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OMJ3SP 




16 


// 


use GPS speed? 










// 


(as opposed to vehicle speed) 


#def ine 
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// 


use vehicle output icon 


#def ine 
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// 


code-3 enabled 


#def ine 


OM TXT 
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// 


txmt pwr enabled 


#def ine 
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// 


use eviews signs? 


#def ine 
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MIN_LEDTIME 


205 


// 


33 










34 
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MAX CD2 DELAY 
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shared 


float Txt Delay; 


// 


39 








// 


40 








// 


41 










42 
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30 


// 


43 








// 


44 










45 


shared 


float StopTime; 
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#def ine 
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#def ine 
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#def ine 
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// is this an emergency vehicle? 



205 // div by 50 for sees to hold LED 1 s 



//////////////////// INTERSECTION CONSTANTS /VARIABLES /////////////////// 



#define PRE_EMERGENCYVEHICLE 10 

#define PRE_POLICEPURSUIT 6 

#define PRE_CLEARINTERSECTION 5 

#define PRE NOLEFTTURN 1 



// sign options (VMS) 
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1 #define PRE_NORIGHTTURN 2 

2 

3 #define MIN_DWLK_SOLID 1.5 // read PED min time 

4 

5 float DWk_Solid[8] ; // time that dont-walk been solid 

6 float Ped_Clear [8] ; // time that dont-walk has been 

7 blinking 

8 float Yel_Timer [8] ; // time at which Yellow last toggled ON 

9 int T_YToR[8]; // amount time for yellow light on 

10 phase 

11 int T WToR[8]; // amount time for maximum ped on phase 
12 

13 int MinTimeToInt; // closest vehicle's ETA to 

14 intersection 

15 int MinDistToInt ; // closest vehicle's distance to 

16 // intersection 
17 

18 #define MAX_PREEMPT_WINDOW 6 // hystersis window for preemption (so 

19 // borderline triggering is avoided) 
20 

21 int PreSigStat [4] ; // current preempt status (includes 

22 type 

23 // of preempt) 

24 int LastEviewUpdate; 
25 

26 #define MAX_EVIEWUPDATE 10 

27 #define MAX_PEDINHIBIT 10 // min hold time once ped preempt 

28 starts 

29 #define MAN_PEDPREEMPT 100 // ID for source on manual ped preempt 
30 

31 #define MAX_EXTACTIVATION 6 // min hold time once extension starts 

32 // (i.e. bus) 
33 

34 #define INT_PERIMETER 3000 // intersection will not preempt for 

35 any 

36 // vehicle outside this perimeter 

37 #define PED PERIMETER 2200 // distance at which ped inputs 

38 // are prevented 

39 #define EXT_PERIMETER 500 // distance at which vehicle-extension 

40 // is actuated 
41 

42 #define IS_SIGREAD 0 // is signal reading active? 

43 #define CFG_TIMETOPREEMPT 20.0 // if signal reading not active, what 

44 is 

45 // min ETA time to use for preemption 

46 // (after critical distance) 

47 . #define ISJ3IGLEGAL 0 // are EViews signs activated 

48 // based on signal condition 

49 (legality)? 
50 

51 #define LOW_PREEMPT 5 // lower end of bracket for low 

52 priority 

53 // (extension) vehicles 
54 

55 #define CRITICAL_DI STANCE 200 // distance under which ETA is ignored 

56 // and vehicle automatically preempts 

57 // (commit distance) 

58 #define MAX TIMETOPREEMPT 30 
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1 #define MAX_LATENCY 30 
2 

3 typedef struct SegmentType_Tag { // position information 

4 float Latl; 

5 float Lonl; 

6 float Lat2; 

7 float Lon2; 

8 float Dist; 

9 float Head; 

10 int Loc; 

11 int IsCritical; 

12 } SegmentType; 
13 

14 #define MAX_S EGMENT S 30 // maximum number of street segments 

15 // accepted per intersections 
16 

17 typedef struct SD Tag { 
18 

19 long UnitID; // unique unit ID 

20 int VehType; // type of vehicle 

21 int StreetWidth; // allowable error in street width (ft) 

22 int Latency; // allowable delay between updates 

23 // before vehicle is marked inactive 

24 // (sees) 

25 int HeadingSpan; // allowable error in heading 

26 int MaxPosLatency; // max time to use dead reckoning w/o 

27 // a valid Pos (i.e. GPS) lock 

28 int DeltaNorth; // used to calibrate intersection to 

29 // north 

30 int PreemptMode; // determines how to handle preempts 

31 float TimeToPreempt; // maximum seconds to preempt all 

32 phases 

33 int ExitDistance; // determines time to output outgoing 

34 // icons 

35 int Thresholding ; // minimum time to preempt before 

36 // intersection threshold 

37 int SourceToPRE[4] ; // orientation of preemption phases 

38 int OutputMode; // output settings 

39 int NumSegments; // number of street segments in memory 

40 float InteLat; // longitude for intersection center 

41 float InteLon; // latitude for intersection center 

42 float DeltaLat; // calibration delta for 1 foot at int 

43 float DeltaLon; 

44 SegmentType 

45 Segments!]; // street segments 
46 

47 ) SD Type; 
48 

49 // preempt mode 

50 #define ALL_RED 0 // 0=ALL SIGNALS GO RED 

51 #define ONE_GREEN 1 // 1=SIGNAL IN VEHICLE (S) DIRECTION 

52 GOES 

53 // GREEN MULTIPLE VEHICLES, MULTIPLE 

54 // DIRECTIONS ALL RED) 

55 
56 

57 /**************************^ 

58 // MAIN 
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1 

2 

3 main() 

4 { 

5 InitBoard ( ) ; 

6 InitComm ( ) ; 

7 InitConf ig ( ) ; 
8 

9 // hit watchdog 

10 hitwdO; 
11 

12 // assign type of hardware 

13 #if IS_VEHICLE 

14 Vehicle_Init () ; 

15 #else 

16 Intersection_Init ( ) ; 

17 #endif 
18 

19 // run background task always 

20 backgnd ( J ; 

21 } 
22 

23 ///////////////////////////////////////////////////////////////////////// 

24 // Config_Init 

25 // Determine if valid parameters are in EPROM; if not, load defaults 

26 // Only called if system is reprogrammed or power is lost 

27 ///////////////////////////////////////////////////////////////////////// 
28 

29 Config_Init () 

30 { 

31 StoredExists=False; 

32 if (EPROM_Exists) { 

33 LoadEPROMData ( StoredExis ts ) ; 

34 } 

35 VerifyStoredData ( ! StoredExists ) ; 

36 } 
37 

38 ///////////////////////////////////////////////////////////////////////// 

39 / 

40 // background task runs when no other task is running 

41 ///////////////////////////////////////////////////////////////////////// 

42 / 
43 

44 backgnd () 

45 { 

46 while (True) { 

47 // do nothing except hit watchdog timer 

48 hitwdO; 

49 } 

50 } 
51 

52 //***********************************^ i J 

53 // INTERSECTION ROUTINES // 

54 //***************+*****+*++*+********+*^ / I 

55 

56 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 / 1 1 1 1 / 1 // 1 1 1 1 1 / 1 1 1 1 1 1 / 1 // / / 1 / 1 / 1 1 1 1 

57 // Task IntMonitor 



// Monitors all incoming traffic signals to determine preemption timing 
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1 // Also sends out periodic "preempt" status signals to all cars 

2 ///////////////////////////////////////////////////////////////////////// 
3 

4 Task_IntMonitor ( ) 

5 { 

6 #if !IS_VEHICLE 

7 for each Phase { 

8 // read current state of traffic signal and ped signal 

9 ReadPhaselnfo (CurRed, CurYel, CurGrn, CurWlk) ; 
10 

11 // dynamically determine ped timing & ped clearance for phase 

12 DeterminePEDTiming (CurWlk) ; 
13 

14 // calculate expected clearance time for this phase 

15 DetermineSignalTiming (CurRed, CurYel, CurGrn) ; 

16 } 
17 

18 CurrentClearanceTime = Max (clearance time of all phases); 

19 

20 if (OutputEnabled) 

21 // if output enabled, send information to all units every 

22 second 

23 SendlnfotoNetwork (phasing information); 
24 

25 if (Preempting) 

26 // adjust hysterisis window (window expanded when vehicle 

27 starts 

28 // preemption, and slowly collapsed) prevents threshold 

29 // triggering ON/ OFF if vehicle is on the border of preemption 

30 DecreaseSizeOf PreemptWindow; 
31 

32 // if preempted, send current PreemptVehicles to all units 'at 1-Hz 

33 PMessage_SendPreemptVehicles ( ) ; 

34 #endif 

35 } 
36 

37 ///////////////////////////////////////////////////////////////////////// 

38 / 

39 // Send a sentence to all signs 

40 ///////////////////////////////////////////////////////////////////////// 

41 / 
42 

43 Eview SendSentence ( ) 

44 { 

45 #if !IS_VEHICLE 

46 hitwd(); 

47 CreateVMSMessage (Eviews (data) ) ; 

48 SendVMSMessage (SignID) ; 

49 #endif 

50 } 
51 

52 ///////////////////////////////////////////////////////////////////////// 

53 // Intersection_Preempt 

54 // Changes current state of preemption for PreemptMonitor 

55 // Handles state of all preempting vehicles 

56 ///////////////////////////////////////////////////////////////////////// 
57 

58 Intersection_Preempt ( ) 
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1 { 

2 #if !IS_VEHICLE 

3 //if car is active, determine if car is already registered; 

4 // otherwise, create new entry for new car 

5 CurrentCar = FindVehiclelnfo (VehiclelD) ; 
6 

7 if (Carlnactive) 

8 // if car inactive (code off) 

9 DeleteVehicleFromList (VehiclelD) ; 

10 else 

11 // store vehicle data (ID, direction, state, speed, etc) 

12 StoreVehicleData (CurrentCar) ; 

13 #endif 

14 } 
15 

16 I / i 1 1 1 1 1 1 1 1 1 1 1 // 1 / 1 / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 / 1 / 1 1 1 1 1 ! 1 1 1 1 / 1 II 1 1 1 1 1 1 1 

17 // Controls DIO for signal preemption (including low priority modulation) 

18 ///////////////////////////////////////////////////////////////////////// 
19 

20 Task_SigPreControl ( ) 

21 { 

22 #if !IS_VEHICLE 

23 // dynamically reads traffic signal state at 10Hz from hardware 

24 input 

25 ReadTraf f icSignals ( SignalMatrix) ; 

26 #endif 

27 } 
28 

29 1 1 1 / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 / 1 1 / 1 // 1 1 / 1 1 1 1 1 i 1 1 1 1 1 / 1 / 1 1 1 / 1 1 / 1 1 / 1 1 1 1 1 1 II 1 1 1 1 /// 1 1 1 II 

30 // Starts/monitors traffic signal preemption and then 

31 // starts/maintains eviews sign preemption 

32 // (based on intersection conditions) 

33 ///////////////////////////////////////////////////////////////////////// 
34 

35 Task_PreemptMonitor ( ) 

36 { 

37 #if !IS_VEHICLE 

38 // init Eviews settings 

39 InitEViewsMem(OFF) ; 
40 

41 for (all vehicles) 

42 // review current preemption vehicle list & activate/deactivate 

43 // VMS icons 

44 SetEViewsMem (CurrentVehicle, VehicleDirection, 

45 VehicleActiveStatus) ; 
46 

47 for (all main phases) { 

48 if (VehicleActive (CurrentPhase) ) 

49 // set all traffic preempt lines using vehicle list 

50 SetControllerPreempt (CurrentPhase) ; 

51 ) 
52 

53 if (PEDTriggered or IntersectionlsPreempted) 

54 //if PED timer is active or intersection is actively 

55 // preempting, prevent PED input 

56 DisablePEDO ; 
57 

58 if (Last E vi ewUpda t e <=MAX_EVI EWU PDAT E ) { 
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1 // if signal was preempted in last update seconds, 

2 // determine signal state for eviews sign 

3 #if (SignalReadActive) 

4 // if signals are available and signal rules are in effect 

5 // for warning sign, determine legality 

6 SetLegalCondition ( IllegalCondition, Phaselnfo) ; 

7 #endif 
8 

9 if (not IllegalCondition) 

10 // IF NOT ILLEGAL SIGNAL CONDITION, transmit information 

11 // to local signs 

12 Eview_SendSentence ( ) ; 
13 

14 if (EViewsOutput Enabled) 

15 - // if enabled, send eview sign information to other 

16 // units on network 

17 SendlnfotoNetwork (sign information); 

18 } 

19 #endif 

20 } 
21 

22 ///////////////////////////////////////////////////////////////////////// 

23 // Intersection_Init 

24 // Initialize intersection variables 

25 ///////////////////////////////////////////////////////////////////////// 
26 

27 Intersection Init { ) 

28 { 

29 #if !IS_VEHICLE 

30 // initialize all phases, preempt lines, transmit lines, etc 

31 IntlnitParameters ( ) ; 
32 

33 - // initialize vehicle preempt list 

34 VehlnitParameters ( ) ; 
35 

36 // schedule traffic light monitor task to run every 1/2 sec 

37 Task_IntMonitor () ; 
38 

39 // start preempt monitor 

40 Task_PreemptMonitor ( ) ; 

41 #endif 

42 ) 
43 

44 ///////////////////////////////////////////////////////////////////////// 

45 // Intersections_Update 

46 // Determines if a vehicle is within the "preempt" boundaries of 

47 // the intersection 

48 ///////////////////////////////////////////////////////////////////////// 
49 

50 Intersection Update () 

51 { 

52 #if !IS_VEHICLE 

53 // compute distance as crow flies to figure intersection point 

54 CrowDistCarToInt = ComputeLatLonDis t ( Positionlnf o ) ; 
55 

56 if (Vehicle is (Code3 or Code2 or Extension) and 

57 CrowDistCarToInt<INT_PERIMETER) { 

58 //if car in code3 or code2, and car within perimeter distance, 
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1 // determine proximity 

2 for (all road segments) 

3 DetermineCarProximityToIntersection (Distance) ; 
4 

5 if (Distance within Preempt boundaries) 

6 // vehicle is within preempt rules, send closest 

7 // segment information 

8 Intersection Preempt ( Enable for Current Road Segment); 

9 } 

10 else { 

11 // code-3 disabled, eliminate code3 

12 Intersection Preempt (Disable for CurrentVehicle) ; 

13 ) ~ 

14 #endif 

15 } 
16 

18 // LOCATION ROUTINES // 

19 //***************************★******* 

20 

21 1 1 1 1 / 1 / / 1 1 1 1 / 1 1 1 1 / 1 1 / 1 1 1 1 / / 1 1 / 1 1 1 1 1 1 / / 1 1 / / / 1 1 1 1 / 1 1 1 / 1 1 1 1 1 / / / / / / / / / 1 1 1 1 1 H 

22 // Initialize ports, sets up position buffers, and starts 

23 // positioning tasks 

24 ///////////////////////////////////////////////////////////////////////// 
25 

26 Vehicle_Init{) • 

27 { 

28 #if IS_VEHICLE 

29 // initialize Vehicle Indicators 

30 InitVehicleVisualDisplay ( ) ; 
31 

32 // open serial channel 

33 InitVehiclePorts ( ) ; 
34 

35 // start position reading 

36 Task_CalculateRealTimePosition ( ) ; 
37 

38 // schedule dead reckoning (supplemental) 

39 Task_DeadReckoning ( ) ; 
40 

41 // schedule dead reckoning 

42 Task_VehicleVisualDisplay ( ) ; 

43 #endif 

44 } 
45 

46 ///////////////////////////////////////////////////////////////////////// 

47 // If positioning is current and valid (i.e. GPS > 3 sats), output 

48 // current info otherwise, if time within MaxLatency, compute dead 

49 // reckoning using speed and heading of vehicle 

50 ///////////////////////////////////////////////////////////////////////// 
51 

52 Position SendAccuratePosition ( ) 

53 { 

54 #if IS_VEHICLE 

55 GetCurrentPosition ( Positionlnf o) ; 

56 if (Positionlnfo is Old) { 

57 // if lag less or equal to MaxLatency, use dead reckoning pos 

58 GetDeadReckon (Positionlnfo) ; 
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I } 

2 

3 if (CurrentVehicle is not stopped longer than threshold) 

4 VehState=ActiveCode; 

5 } 
6 

7 SendlnfotoNetwork (Vehicle Position & State Information); 

8 #endif 

9 } 
10 

II ///////////////////////////////////////////////////////////////////////// 

12 // Indefinitely reads position data (i.e. from GPS serial port) 

13 ///////////////////////////////////////////////////////////////////////// 
14 

15 Task_CalculateRealTimePosition ( ) 

16 { 

17 #if IS_VEHICLE 

18 // indefinitely calculate vehicle position 

19 while (True) { 

20 CalculateBestPosition (Def ault=GPS) ; 

21 } 

22 #endif 

23 } 
24 

25 / / / 1 / 1 1 / 1 / 1 1 / / / 1 / / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II / 1 1 1 1 1 1 i 1 1 / 1 1 / 1 1 1 1 / / 1 / 1 1 / 1 1 1 II 

26 // Computes current dead reckoning position 

27 ///////////////////////////////////////////////////////////////////////// 
28 

29 Task_DeadReckoning ( ) 

30 { 

31 #if IS_VEHICLE 

32 // read current speed (kph) 

33 ReadSpeed (OBDInfo) ; 
34 

35 //if OBD disabled, assume car is off 

36 if (OBDInfo. Disabled) 

37 // if OBD disabled, shut off transmitter 

38 TxmtTurn(OFF) ; 
39 

40 // compute distance travelled since last update (ft/sec) 

41 DistanceTraveled = IntegrateSpeed ( SpeedHistory ) ; 
42 

43 // get current heading 

44 Heading Read ( ) ; 
45 

46 // read code staus, handle timing to indicate when last code was 

47 seen 

48 ReadCodeStatus (VehType, CodeMatrix) ; 
49 

50 if (OBDSpeed>0 Or PositionSpeed>0 Or CodeChange) 

51 // if vehicle is moving or code3/code2/ext was just turned on, 

52 // force fresh code call 

53 MakeCurrentCode (CodeMatrix) ; 

54 else 

55 //if vehicle is stopped, increment stop counter 

56 DelayCurrentCode (CodeMatrix) ; 

57 #endif 

58 } 
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1 

2 //****+****+*********************^ 

3 // COMMUNICATION ROUTINES // 
5 

6 ///////////////////////////////////////////////////////////////////////// 

7 // Comm_DataMove Value 

8 // Adds a new data value to data message 

9 ///////////////////////////////////////////////////////////////////////// 
10 

11 Comm_DataMoveValue ( ) 

12 { 

13 SelectDataType (DataSize) ; 

14 AssignDataValue (DataSize, DataValue, OperationType ) ; 

15 } 
16 

17 1 1 1 1 1 1 1 1 1 f 1 1 1 1 1 1 1 / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 J I If 1 1 1 1 1 1 II 1 1 1 1 It I / 1 1 1 1 

18 //////// 

19 // Sends/Receives POS message type 

20 / 7 7 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 / 1 II 1 1 1 1 1 1 

21 //////// 
22 

23 PMessage_POS () 

24 { 

25 Comm_DataMoveValue ( VehType, VehState, GSpeed, VSpeed, Lat, Lon, 

26 PosQuality, GHeading, VHeading) ; 
27 

28 if (DataMode==WRITE) 

29 //if vehicle, send position info to network 

30 SendlnfotoNetwork (Vehiclelnfo) ; 
31 

32 if ( DataMode==READ ) 

33 //if intersection, update preemption status for 

34 // notifying vehicle 

35 Intersection Update () ; 

36 } 
37 

38 1/1 //////I///I/I /I lllllllllllllllllllll ////////// ////// /// /// /////// ///// 

39 //////// 

40 // Sends/receives intersection line segment message type 

41 ///////////////////////////////////////////////////////////////////////// 

42 //////// 
43 

44 PMessage SEG ( ) 

45 { 

46 #if !IS_VEHICLE 

47 Comm_DataMoveValue (CILat , CILon, C2Lat, C2Lon, 

48 Distance, Heading, Location, IsCritical ) ; 
49 

50 if ( DataMode==READ) 

51 //if Intersection, read in all street segments and config info 

52 // for permanent store 

53 StoreMapAndConf ig ( ) ; 

54 #endif 

55 } 
56 

57 ///////////////////////////////////////////////////////////////////////// 

58 // Executes a manual preempt command 
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I ///////////////////////////////////////////////////////////////////////// 

2 

3 PMessage_SMP ( ) 

4 { 

5 #if !IS_VEHICLE 

6 Comm_DataMove Value (Source, Direction, VehType, VehState ) ; 
7 

8 if ( DataMode==READ) 

9 // enable manual (remote) preempt of phase/ped signals 
10 Intersection_Preempt ( ) ; 

II #endif 
12 } 

13 

14 ///////////////////////////////////////////////////////////////////////// 

15 //////// 

16 // Maintains preemption LED statusm in vehicle 

17 1 1 1 1 1 1 1 1 1 II 1 1 1 1 / 1 1 1 1 / 1 1 1 1 1 1 1 1 // 1 1 1 1 1 1 II 1 1 / 1 1 / 1 1 1 1 / 1 1 / 1 1 / 1 1 1 1 1 / 1 / H I // 1 / 1 1 

18 //////// 
19 

20 Task_VehicleVisualDisplay ( ) 

21 { 

22 #if ISJVEHICLE 

23 while (True) { 

24 // indefinitely convert vehicle status and collision avoidance 

25 // information into visual in-car indicators (LED's, PDA's, or 

26 // PC) - maps, text warnings, LED's 

27 OutputLEDInfo(LEDMatrix) ; 

28 OutputPCInf o (PCInfo) ; 

29 OutputPDAInfo(PDAInfo) ; 

30 } 

31 #endif 

32 ) 
33 

34 ///////////////////////////////////////////////////////////////////////// 

35 //////// 

36 // Handles currently active vehicle preempts 

37 1 1 1 1 1 //// 1 1 / 1 1 1 1 1 / 1 1 // 1 1 1 1 1 1 1 1 II 1 1 1 1 / 1 1 1 1 1 1 1 1 1 1 1 1 / 1 1 / 1 1 II / 1 1 1 / 1 // 1 / 1 / 1 / H 

38 //////// 
39 

40 PMessage SendPreemptVehicles ( ) 

41 { 

42 Comm DataMoveValue (All Vehicles Listed); 
43 

44 if ( DataMode==READ) { 

45 #if ISJVEHICLE 

46 // generate visual display based on all actively 

47 preempting 

48 // vehicles if only one vehicle is preempting and it is 

49 // this vehicle, light green LED if more than one vehicle 

50 //is preempting and it includes this vehicle, 

51 // light yellow LED 

52 VehicleVisualDisplayUpdate (AllActiveVehicleStatus ) ; 

53 #endif 

54 } 

55 else { 

56 #if ! ISJVEHICLE 

57 // notify all units of those cars who have preempted 

58 // in last 2 seconds 
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1 SendlnfotoNetwork (AllActiveVehiclesInf o) ; 

2 #endif 

3 } 

4 } 
5 

6 ///////////////////////////////////////////////////////////////////////// 

7 // Outputs intersection calculated information 

8 // Includes derived parameters (last trigger per phase, etc) 

9 ///////////////////////////////////////////////////////////////////////// 
10 

11 PMessage_ISI () 

12 { 

13 #if !IS_VEHICLE 

14 Comm_DataMoveValue (ISI_Type, IntParaml, IntParam2, 

15 IntParam3, IntParam4, IntParamS, 

16 IntParam6, IntParam7, IntParam8) ; 
17 

18 if (DataMode==WRITE) 

19 SendlnfotoNetwork ( IntersectionPhaselnf o ) ; 

20 #endif 

21 } 
22 

23 1 1 1 1 1 ! 1 1 1 1 / 1 1 1 1 1 1 1 1 / 1 1 1 1 II 1 1 / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 / 1 / 1 1 1 1 1 1 1 1 1 1 1 / 1 1 1 1 1 / 1 / 1 1 

24 // Outputs intersection monitor information 

25 // Includes red,grn,yel phasing and red, yellow, ped clearance 

26 ///////////////////////////////////////////////////////////////////////// 
27 

28 PMessage IMO ( ) 

29 { 

30 #if !IS_VEHICLE 

31 Comm_DataMove Value ( I Phase, I SignalType) ; 

32 ~ 

33 if ( DataMode==READ) 

34 SendlnfotoNetwork (IntersectionMonitorlnfo) ; 

35 #endif 

36 } 
37 

38 I f 1 1 1 1 1 1 1 1 / 1 1 1 1 If 1 1 1 1 1 1 1 1 II / f 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 f 1 1 1 1 1 1 1 1/ 1 1 1 1 1 1 1 1 1 1 1/ 1 / 1 1 fll 

39 // Sends/receives IID message type 

40 // Intersection configuration information 

41 ///////////////////////////////////////////////////////////////////////// 
42 

43 PMessage IID() 

44 { 

45 #if !IS_VEHICLE 

46 Comm_DataMoveValue ( StreetWidth, Latency, HeadingSpan, OutputMode, 

47 TimeToPreempt, DeltaNorth, PreemptMode, 

48 ExitDistance, ThresholdLag, PreemptOrient ) ; 
49 

50 if (DataMode==WRITE) 

51 // send information back to requestor 

52 SendlnfotoNetwork ( IntersectionConf iglnf o) ; 
53 

54 if ( DataMode==READ) 

55 StorelntersectionConfiglnfo ( IntersectionConf iglnf o) ; 

56 #endif 

57 ) 
58 
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1 ///////////////////////////////////////////////////////////////////////// 

2 // Sends/receives VID message type 

3 ///////////////////////////////////////////////////////////////////////// 
4 

5 PMessage_VID() 

6 { 

7 #if IS_VEHICLE 

8 Comm_DataMove Value (VehType, OutputMode, MaxPosLatency ) ; 
9 

10 if (DataMode==WRITE) 

11 // send information back to requestor 

12 SendlnfotoNetwork (VehicleConf iglnfo) ; 
13 

14 if (DataMode==READ) 

15 // set vehicle config info 

16 SetVehicleConfiglnfo (VehicleConf iglnfo) ; 

17 #endif 

18 } 
19 

20 1 1 1 1/ 1 1 / 1 1 1 1 1/ 1 1 1 1 1 1 1 1 1 1 1 II I / II / II 1 1 1 1 1 / 1 / 1 1 1 1 / 1 1 1 / 1 // 1 / 1 1 / 1 1 1 1 / 1 1 / 1 / 1 / / 1 

21 // Allows change of Unit ID 

22 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 II I II / 1 1 / 1 / 1 / / 1 / 1 1 / 1 / / / / 1 / / 1 
23 

24 PMessage CID() 

25 ( 

26 Comm_DataMo ve Value (NewID, UnitType ) ; 
27 

28 if (DataMode==READ) 

29 SetVehiclelDInfo (VehiclelDInfo) ; 

30 ) 
31 

32 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 / 1 / / 1 1 1 1 / 1 / 1 1 / 1 / 1 1 

33 // Write stored information to EPROM 

34 II 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II I II 1 1 1 1 1 1 1 1 / 1 / / 1 1 1 1 1 1 1 1 1 / 1 1 1 1 
35 

36 PMessage_WRT ( ) 

37 { 

38 WriteStoredDataO ; 

39 ) 
40 

41 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 III / II 1 1 1 / 1 / / 1 /I / / 1 / / 1 / / / 1 / / 1 1 / 1 

42 // Sends/receives string message type 

43 II 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 II 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 / 1 / / / 1 1 1 1 1 1 1 1 1 1 / / 1 
44 

45 PMessage_MSG() 

46 { 

47 Comm DataMoveValue (MessageLen, Message ) ; 
48 

49 if (DataMode==WRITE) { 

50 SendlnfotoNetwork (Messagelnf o) ; 

51 } 
52 

53 II 1 1 II I II I III I II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 II 1 1 1 1 1 II 1 1 1 1 1 1 1 1 / 1 / / / 1 / / 1 1 1 1 1 / 1 1/ 1 

54 // Sends/receives string message type 

55 1 1 1 1 If 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 / 1 / / 1 1 1 / 1 1 / / 1 1 1 / 1 / / 1 / 1 1 / 1 
56 

57 PMessage DIO() 

58 { 
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1 Comm DataMoveValue (Channel, Operation, Value) ; 

2 

3 ReadDirectPortDigitallO (PortDIOInfo) ; 

4 

5 SendlnfotoNetwork (PortDIOInfo) ; 

6 } 
7 

8 ///////////////////////////////////////////////////////////////////////// 

9 // Parses data from a packet and calls appropriate function to handle 

10 // the data 

11 ///////////////////////////////////////////////////////////////////////// 
12 

13 Comm_ParseData ( ) 

14 ( 

15 SelectMessage (MessageType) ; 

16 } 
17 

18 ///////////////////////////////////////////////////////////////////////// 

19 // Packs data and sends to comm 

20 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 / 1 / 1 1 1 1 1 1 / 1 II I II 1 1 1 1 1 1 / 1 1 1 1 II 1 1 1 1 1 1 1 1 II / 1 / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 / 1 
21 

22 SendlnfotoNetwork (Data) ; 

23 { 

24 Packet=BuildPacket (Marker, Length, Checksum, MessageType, PacketID, 

25 SourcelD, DestinationID, Data) ; 
26 

27 if (CommlsTDMA) 

28 AddTDMAHeader (Packet) ; 
29 

30 // send packet to transceiver (wireless net) 

31 SendPacketToTransceiver (Packet) ; 
32 

33 // send packet out local port 

34 SendPacketToLocalSerial (Packet) ; 

35 } 
36 

37 ///////////////////////////////////////////////////////////////////////// 

38 // Receives packet info, unstuffs information, parses packet info, 

39 // and then requests processing of data message 

40 ///////////////////////////////////////////////////////////////////////// 
41 

42 Task ReceivePacket ( ) 

43 { 

44 while (True) { 

45 Data=ReadPacket (Marker, Length, Checksum, MessageType, 

46 PacketID, SourcelD, DestinationID, Packet); 

47 Comm ParseData ( Data) ; 

48 ) 

49 } 
50 

51 ///////////////////////////////////////////////////////////////////////// 

52 // Indefinitely reads all incoming messages from the transceiver 

53 ///////////////////////////////////////////////////////////////////////// 
54 

55 indirect 

56 Task CommReadO 

57 ( " 

58 while (True) { 
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1 Data = ReadLowLevelComm(IncomingPorts) ; 

2 if (UnitlsMasterNode) 

3 // if unit is considered a master node in the network, 

4 // repeat the message to all local units 

5 SendlnfotoNetwork (Data, REPEAT); 

6 } 

7 ) 

8 // End of Code 
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